The architecture of the traditional EJB classloading scheme is such that any changes to the EJB implementation (impl) class forces the developer to go through a full redeployment (undeploy and redeploy cycle) for the changes to take effect. This results in unnecessary work being done, since much of the EJB deployment code that had to execute has no direct dependency on the EJB impl class. One of the downsides is that it takes longer than necessary to have the new EJB impl changes take effect.
Another problem is that a full redeployment can be very disruptive, since it invalidates all references to the EJB and forces clients to obtain those references again to continue to invoke on the EJB.